前一篇討論「Ollama 與 vLLM：服務模型相同，營運行為卻不同」，這篇聚焦「併發一上來，瓶頸先出現在哪裡」，並沿用同一組輸入、環境與判讀規則，避免只做名詞比較。

今天要回答的問題

逐步增加 concurrency，觀察 TTFT、總延遲、排隊與 GPU 飽和點，找出平台的 knee point。

工程邊界

AI Serving 的瓶頸常先表現在 Queue

單人測試只看到模型的服務時間；多人同時進來後，還多了等待時間。簡化來看：使用者感受到的延遲 = queue wait + service time。當 arrival rate 長期超過系統可處理速率，單純讓 request 一直排隊只會讓延遲無上限成長。

所以平台需要 backpressure 或 admission control：限制最大併發、設定 queue 上限、超時、拒絕策略，必要時把低優先工作延後，而不是把整台機器拖到所有人都不能用。

一個可以直接重現的起點

測試方法

固定模型版本、context 長度、輸出 token 上限與硬體狀態，再逐步提高 concurrency。每個測試至少記錄 P50/P95、TTFT、tokens/s、成功率，以及 CPU、RAM、GPU utilization、VRAM 與磁碟 I/O。不要只跑一次；至少重複三輪，避免把模型 warm-up 或背景工作誤判成系統能力。

# 範例：測試期間同步記錄 GPU 狀態
nvidia-smi dmon -s pucvmet -d 1

# 另一個終端保留系統層資訊
vmstat 1
iostat -xz 1

先把併發階梯寫成測試設定

先把「固定模型後將 concurrency 依 1、2、4、8 階梯加壓」需要固定的輸入、版本與環境集中在同一份小型測試計畫；函式名稱代表實際工具。

plan = {
    "change": '固定模型後將 concurrency 依 1、2、4、8 階梯加壓',
    "fixed": ("input", "version", "environment"),
    "metrics": ('成功率', 'TTFT', 'P95', 'throughput', 'queue', 'GPU'),
}
for round_no in range(1, 4):
    sample = run_once(plan)  # 接上實際壓測或維運工具
    save_sample(round_no, sample)

驗證與落地方式

驗證可從「固定模型後將 concurrency 依 1、2、4、8 階梯加壓」開始。先以未施加變更的狀態建立 baseline，再執行目標條件，最後確認服務能回到穩定狀態。三個階段使用相同輸入與觀察時間窗，可降低 warm-up、cache 與背景工作造成的誤判。若測試包含故障或資源壓力，應限定在隔離環境，事先設定停止條件與復原方式。

觀察資料要同時涵蓋使用者體感、服務行為與主機資源。這篇優先比較：成功率、TTFT、P95、throughput、queue、GPU。單看資源使用率無法代表服務健康；吞吐提高也可能伴隨排隊、錯誤率或尾端延遲惡化。至少重複三輪並保留每輪條件，才能區分穩定趨勢與偶發尖峰。

常見誤判

• 只看平均值，忽略 P95、錯誤率與恢復時間，容易低估少數使用者遇到的嚴重延遲。
• 同時更換模型、參數、資料與基礎設施，數字即使改善，也無法判斷真正原因。
• 只驗證正常路徑，沒有測試容量邊界、依賴失效與復原流程，上線後仍可能在第一個異常點失守。

上線前檢查

確認監控能回答「何時開始、影響多大、哪一層先異常」，並為超時、容量與復原設定可操作門檻。所有門檻都應對應負責人與處置方式；無法觸發行動的數字只適合分析，不適合作為告警。

如何閱讀結果

結果可分成使用者影響、服務訊號與資源訊號三層閱讀。先確認錯誤率與延遲是否超出承諾，再沿時間線追查 queue、依賴與主機資源。若只有 GPU 或 CPU 使用率改變，但使用者指標沒有同步變化，只能視為線索，不能直接宣告根因。

單次測試適合發現風險，不足以證明長期容量。正式採用前還要加入較長時間的穩定性測試與版本回歸，確認重新啟動、流量波動及依賴短暫異常不會改變原本結論。

結果判讀

判讀不只看最大或最漂亮的數字。這一天真正要回答的是：找出第一個 SLO 失守點，而不是只找最高吞吐。

如果核心指標改善，但錯誤率、尾端延遲、資源成本或恢復能力變差，這代表取捨，而不是無條件進步。相反地，沒有改善也不是無效結果；至少能排除一條看似合理、實際上不值得增加複雜度的路。

今天的結論

今天的工程判斷是：找出第一個 SLO 失守點，而不是只找最高吞吐。無論結果支持或否定原本假設，都必須保留完整條件，才能和下一天的實驗串在一起。

下一篇將處理：VRAM 容量規劃：模型大小不是唯一答案。

參考資料

• Google SRE Book
• Prometheus Documentation
• vLLM Documentation
• PostgreSQL Backup and Restore